Change Baseline version?

SystemAdmin - Wed Apr 29 20:16:04 EDT 2009
Hi,

I have been trying to post a reply but it's being rejected on the basis of "Disallowed content detected" - this doesn't tell me exactly what's disallowed so I cannot for the life of me work out what I have written to cause this. So my possible solution is attached as a file.

Tony_Goodman - Thu Apr 30 02:46:23 EDT 2009
Paul,

Three X's in a row are what stopped your post!

SystemAdmin - Thu Apr 30 03:35:10 EDT 2009
Tony Goodman wrote: Three X's in a row are what stopped your post!

A tad sensitive don't you think?

So here is my response without the three innocent X's then! BTW: We have a brand of beer here in Australia that is named as 3 consecutive X's. There would be a civil riot if that was banned.

***************************************************************
Hi,

As far as I know, at least ever since the advent of DOORS version 5, there is no way to wind back or alter an allocated baseline number to a DOORS Module. "Tricking" the DOORS system could wreak havoc, particularly if the Baseline Sets feature has been used.

I have been down this path of trying to keep DOORS Module versions in synch with Document versions before - it's a pain because of the very incident that you have encountered. It's easy to get out of synch.

To decouple from this problem I have been doing the following for many years.

I assume that your documents have a Change History Table of some sort that lists all of the past released versions, date of release and a brief description of change. Assume that the current document version is lets say version 3.0 and the current version of the corresponding DOORS module is lets say version 5.0 - these are clearly out of synch.

When a new version of the document is to be cut we know in advance that the DOORS module will be advanced to version 6.0 and the document will be advanced to version 4.0.

As a personal preference which you may elect not to follow, I never advance a new major version of a DOORS module until the paper document is fully signed off - it's amazing how many times the document comes back with just "one more change please" and then you have to repeat the process and advance another module version.

After exporting the current working version to MSWord, the Change History Table is modified with an entry for the new version 4.0 of the document. In the Description of Change for version 4.0, I include a version cross reference to DOORS, something to the effect of:

The content of this document revision has been sourced from the DOORS Requirements Management Tool.
DOORS Module Name: XYZ Specification
DOORS Module version Used: 6.0

When the ink is dry on the signatures of the document, I then roll the baseline in DOORS but in the Module Version Description box I also include a version cross reference to the version of the paper document, something to the effect of:

This version is the source content for the following document
Document Name: XYZ Specification
Document Number: ABC-123-ZZZ
Document version: 4.0

So this provides full version traceability - whilst it may seem onerous - it's not - it's just a new habit that needs to be formed and procedurally documented in your Requirements Management Plan.

If this is not for you - then perhaps this is what you need to do as an exception just for this version that your trying to release and then try and get things back into synch for the next version.

One other possibility is just make the document version equal to whatever the version is in the DOORS module. As long as each version number is unique and never goes backwards (e.g: 2.0, 2.0A, 3.1Z etc) you have satisfied version labelling and traceability criteria. However, I have found this is harder to sell as there are many pedants out there who believe that version numbering labels must always be incremental and sequential and never skip a number (e.g: 1.0, 2.0, 2.1, 2.2, 3.0 etc).

Tony_Goodman - Thu Apr 30 09:07:00 EDT 2009
Interesting to hear about the beer.

Over here in the UK we have a beer named with 4 consecutive X's, which they claim is "The Australian for lager".

Did they add an extra X so as not to offend the delicate poms?

BTW, we also have a home grown real ale called 6X.

SystemAdmin - Thu Apr 30 03:35:10 EDT 2009
Tony Goodman wrote: Three X's in a row are what stopped your post!

A tad sensitive don't you think?

So here is my response without the three innocent X's then! BTW: We have a brand of beer here in Australia that is named as 3 consecutive X's. There would be a civil riot if that was banned.

***************************************************************
Hi,

As far as I know, at least ever since the advent of DOORS version 5, there is no way to wind back or alter an allocated baseline number to a DOORS Module. "Tricking" the DOORS system could wreak havoc, particularly if the Baseline Sets feature has been used.

I have been down this path of trying to keep DOORS Module versions in synch with Document versions before - it's a pain because of the very incident that you have encountered. It's easy to get out of synch.

To decouple from this problem I have been doing the following for many years.

I assume that your documents have a Change History Table of some sort that lists all of the past released versions, date of release and a brief description of change. Assume that the current document version is lets say version 3.0 and the current version of the corresponding DOORS module is lets say version 5.0 - these are clearly out of synch.

When a new version of the document is to be cut we know in advance that the DOORS module will be advanced to version 6.0 and the document will be advanced to version 4.0.

As a personal preference which you may elect not to follow, I never advance a new major version of a DOORS module until the paper document is fully signed off - it's amazing how many times the document comes back with just "one more change please" and then you have to repeat the process and advance another module version.

After exporting the current working version to MSWord, the Change History Table is modified with an entry for the new version 4.0 of the document. In the Description of Change for version 4.0, I include a version cross reference to DOORS, something to the effect of:

The content of this document revision has been sourced from the DOORS Requirements Management Tool.
DOORS Module Name: XYZ Specification
DOORS Module version Used: 6.0

When the ink is dry on the signatures of the document, I then roll the baseline in DOORS but in the Module Version Description box I also include a version cross reference to the version of the paper document, something to the effect of:

This version is the source content for the following document
Document Name: XYZ Specification
Document Number: ABC-123-ZZZ
Document version: 4.0

So this provides full version traceability - whilst it may seem onerous - it's not - it's just a new habit that needs to be formed and procedurally documented in your Requirements Management Plan.

If this is not for you - then perhaps this is what you need to do as an exception just for this version that your trying to release and then try and get things back into synch for the next version.

One other possibility is just make the document version equal to whatever the version is in the DOORS module. As long as each version number is unique and never goes backwards (e.g: 2.0, 2.0A, 3.1Z etc) you have satisfied version labelling and traceability criteria. However, I have found this is harder to sell as there are many pedants out there who believe that version numbering labels must always be incremental and sequential and never skip a number (e.g: 1.0, 2.0, 2.1, 2.2, 3.0 etc).

SandraCoppedge - Fri Aug 05 11:50:42 EDT 2011
I'm needing help deciding how to manage changing requirements from version to version of documents.

For example:

Document version 5.11.1:
SRS-101 The car is red.

Document version 5.11.1 R1:
SRS-101 The car is red with purple flakes.

Keep in mind that BOTH of these documents will remain active and in use at the same time for 2 versions of the same car.
My question is this: Do I export the document for 5.11.1 and now it's baselined, so be it, it's in a vault somewhere and signed and just assume that the the DOORS repository is live and I will never need to export that same document again? Or do I copy SRS-101, make the second requirement SRS-102 and label the 101 as belonging to 5.11.1 and 102 as belonging to 5.11.1 R1 and maybe have a field that says these are the same requirement, just different versions of the same requirement. Because, it could be for 5.11.2 or 5.12 it goes back to "The car is red." again!

I'm having a hard time figuring how how to version my repository to keep up. Should I just make an entire copy of the entire module for every version? That doesn't seem like good data maintenenace. Any help in philosophy would be appreciated here.

SandraCoppedge - Fri Aug 05 11:50:42 EDT 2011
I'm needing help deciding how to manage changing requirements from version to version of documents.

For example:

Document version 5.11.1:
SRS-101 The car is red.

Document version 5.11.1 R1:
SRS-101 The car is red with purple flakes.

Keep in mind that BOTH of these documents will remain active and in use at the same time for 2 versions of the same car.
My question is this: Do I export the document for 5.11.1 and now it's baselined, so be it, it's in a vault somewhere and signed and just assume that the the DOORS repository is live and I will never need to export that same document again? Or do I copy SRS-101, make the second requirement SRS-102 and label the 101 as belonging to 5.11.1 and 102 as belonging to 5.11.1 R1 and maybe have a field that says these are the same requirement, just different versions of the same requirement. Because, it could be for 5.11.2 or 5.12 it goes back to "The car is red." again!

I'm having a hard time figuring how how to version my repository to keep up. Should I just make an entire copy of the entire module for every version? That doesn't seem like good data maintenenace. Any help in philosophy would be appreciated here.

llandale - Fri Aug 05 16:00:18 EDT 2011
All solutions are clumsy.

As suggested you could have separate sibling objects with text that is similar and some attribute indicating which requirement applies to which release versions. Clever filtering is needed when you export a version.

You could also have just one object whose Text contains the standard requirement. You could then add new Text attributes for each different version, and include something in it when the version's requirement is different than the 'Standard'. An Attr-DXL for each version could be used to display the Version's requirement, if the Text is null it displays the Standard text instead. A view for each version and you have something rather readable.

Object Text: Its Red
R1 Text:
R2 Text: Its Red with Flakes. Purple flakes not slow-thinkers.
R3 Text:

The R1 attr-DXL would notice R1 Text is empty and so display "Its Red" instead.

This unfortunately requires you to give up on the notion that "Object Text" is definitive.

• Louie

SandraCoppedge - Mon Aug 08 14:13:21 EDT 2011
I do like the idea of using option attr-DXL text, BUT, we have developers that search DOORS requirements for applicable requirements for their Peer Reviews. This would become a problem if they are simply searching Object Text, correct? In this case, I woud have to set up views of the separate versions for them to search, wouldn't I?

llandale - Mon Aug 08 18:48:27 EDT 2011
You would want to set up views, one for each whatever; but these views won't relieve the other folks doing searches to know to search the attr-DXL name that corresponds to their whatever. If they insist on Object Text searches they you are obligated to have one module per version.

Like I said, all solutions are clumsy.

• Louie

SandraCoppedge - Tue Aug 09 10:51:00 EDT 2011
I can't believe there's not a cleaner solution to this.
Does NOONE out there run into this?

I'm beginning to think that there should be a separate requirement for each version...

Section 5.5.5 Car Color
SRS-100 Threshold The car shall be red.
SRS-101 Threshold The car shall have a clear coat.

Section 5.5.5.1 Car Color Specks
SRS-102 Objective The car specks shall be shiny.
SRS-203 Objective The car specks shall be purple.

In other words, write the requirements somehow so that the specks are included IF they apply. Ideas?